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ABSTRACT 

APECS is the distributed control system of the new Atacama Pathfinder Experiment (APEX) telescope located on the Llano de Chajnantor at 
an altitude of 5107 m in the Atacama desert in northern Chile. APECS is based on Atacama Large Millimeter Array (ALMA) software and 
employs a modern, object-oriented design using the Common Object Request Broker Architecture (CORBA) as the middleware. New generic 
device interfaces simplify adding instruments to the control system. The Python based observer command scripting language allows using many 
existing software libraries and facilitates creating more complex observing modes. A new self-descriptive raw data format (Multi-Beam FITS 
or MBFITS) has been defined to store the multi-beam, multi-frequency data. APECS provides an online pipeline for initial calibration, observer 
feedback and a quick-look display. APECS is being used for regular science observations in local and remote mode since August 2005. 

Key words. Telescopes - Methods: data analysis - Methods: numerical - Astronomical data bases: miscellaneous 



1. Introduction 

Modern radio observatories such as the new APEX 1 sub- 
millimeter telescope (Gtiste n et al. this volum e! need complex 
control software to coordinate the various hardware systems 
for the desired observations. The individual instrument con- 
trol computers and auxiliary devices like synthesisers, etc. are 
typically distributed among different locations throughout the 
observatory so that network communication is essential. Real- 
time calculations are necessary to track the target positions and 
handle observing patterns. Monitoring hardware properties and 
environmental conditions is important. 

Since APEX is an experimental project, it will feature nu- 
merous bolometer cameras and heterodyne array receivers op- 
erating in the atmospheric windows between 150 GHz and 
1 .5 THz. These frontends are complemented by a set of dif- 
ferent continuum and spectral line backends to analyse the sig- 
nals. Frontends and backends can be connected to each other in 
many different ways for observing. The APEX control system 
(APECS. fMuders 2 005 1 therefore needs to be flexible to han- 
dle the many different instruments and their combinations and 
it must be easily extensible to include new devices. As a con- 
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sequence of the instrument complexity, the data formats for the 
raw and calibrated data must be able to store all setup details. 

APECS needs to provide the standard radio observing 
modes like pointing, skydip, on-off integrations or on-the-fly 
mapping. Since observations at submillimeter wavelengths are 
strongly affected by atmospheric absorption, new calibration 
and observing modes need to be tried out and the control soft- 
ware must support testing and implementing them in a sim- 
ple fashion. Radio astronomers also often wish to use a script- 
ing language to create observing macros. An online pipeline 
is needed for feedback concerning the calibrations and for a 
quicklook display of the scientific data. Finally, the location of 
APEX at a very high site requires remote observing capabilities 
right from the beginning. 

In this letter we describe the design choices for APECS to 
fulfill the above requirements and we highlight the most im- 
portant parts of the software developments that were made at 
the Max-Planck-Institut fur Radioastronomie over the course 
of several years until now. The software has been iterated using 
user feedback that was collected during the commissioning and 
early science observing phase of the APEX telescope in 2004. 
Overall, APECS now provides a fully featured single-dish tele- 
scope observing system that has been used by staff and visit- 
ing astronomers for regular science observations since August 
2005. 
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2. APECS Design & Implementation 

The APECS design phase began with evaluating existing ra- 
dio telescope control systems with the aim of re-using as much 
software as possible in order to save manpower. The systems 
under consideration were, however, often tightly connected to 
certain obsolete hardware choices or difficult to maintain with- 
out the special knowledge of the original developers. 

Since APEX is a copy of one of the ALMA prototype an- 
tennas that were tested at the VLA site in New Mexico, we 
closely followed the developments of the initial ALMA control 
software. Although a prototype, it already showed the modern 
development approach using a common network communica- 
tion protocol aimed at a flexible and maintainable software. 
The identical telescope hardware interfaces of APEX and the 
ALMA antennas allowed immediate application of the real- 
time software which is usually very difficult to develop and test. 
In addition, the participation of some of us in the then and cur- 
rent ALMA software developments helped to master the initial 
learning curve quite fast and allowed for some influence on the 
software design. 

For the above reasons we decided to re-use the emerg- 
ing ALMA software. APECS is thus based on the frame- 
work of the so-called ALMA Common Software (ACS, 
Raffi, Chiozzi & Glendenning 2001 1 which uses the Common 
Object Request Broker Architecture (CORBA, IOMG 19 99 1, 
an industry standard to provide a multi-language, vendor- 
independent network communication layer. ACS delivers the 
infrastructure for representing hardware devices in software via 
distributed objects, i.e. software components that can be de- 
ployed close to the hardware but accessed in the same manner 
from anywhere in the control system without having to know 
the implementation details. In addition, ACS provides means 
for automatic monitoring and logging. 

APECS also re-uses parts of the ALMA Test Interferometer 
Control Software (TICS, |Glendenning et al. 2001) which 
mainly provides the real-time system for basic antenna con- 
trol including astronomical coordinate system handling and ob- 
serving pattern elements. TICS being a prototype software, we 
needed to improve its stability in some areas for the normal sci- 
ence operations. This was done in collaboration with some of 
the ALMA developers so that the effort was relatively small. 

The ACS and TICS packages fulfill the requirements of 
common network communication, automatic monitoring, real- 
time tracking and remote observing. However, the overarch- 
ing software to use all hardware devices in a coordinated way 
necessary for astronomical observations was only rudimentar- 
ily implemented in TICS because it aimed only at testing the 
ALMA prototype antenna performance. It was not suitable for 
operating a telescope 2 . We therefore needed to develop that part 
of the software ourselves. 

We began the development by defining the generic instru- 
ment and device interfaces (cf. section l2~Tt and the raw data 
format interface (cf. section l2~2l since these areas needed to be 
stable early on. Subsequently, we developed the observer in- 

2 For ALMA this functionality is currently under development but 
its time scale does not match with the APEX schedule and it will not 
support multi-beam array receivers. 



terface which provides a scripting language for observing (cf. 
section l2~3l . the so-called Observing Engine to coordinate all 
hardware devices and software tasks, the raw data writer (cf. 
section l2~31 i and the online calibrator pipeline (cf. section l2~5l . 

These APECS core components are organised as a pipeline 
system (see fig. [Q. Observations are defined using so-called 
Scan Objects which contain the full description of the next 
observation, i.e. the instrument setup details, target coordi- 
nate information and the desired observing patterns. The Scan 
Objects, that are created by the observer command line inter- 
face, are sent to the Observing Engine which sets up all nec- 
essary devices, controls the data acquisition and triggers the 
online data calibration, reduction and display. 

Aside from this main pipeline, we also developed a generic 
graphical monitoring tool to view any system property and its 
alarm states and an automatic observation logger that simpli- 
fies keeping detailed records of the target, instrument setup and 
observing mode used for each scan. 

Most of the APECS applications are written in Python 
( Rossum & D rake Jr. 200 1> which was chosen because a 
scripting language is required for the user interfaces for observ- 
ing and offline calibration, and because ACS provides means to 
access the middleware from this language. We also use Python 
for the non-interactive processes since its high-level structures 
allow for a very efficient development of the complex book- 
keeping needed for instrument and pattern setups. In addition, 
there are Python wrappers to many existing compiled libraries 
to perform heavy duty numerical calculations such as the at- 
mospheric calibration or processing the high raw data rates of 
up to several MB/s. Overall, we believe that these advantages 
outweigh possible problems like the dynamic typing. 

In the following sections we highlight some details of the 
most important pieces of the APECS developments. 

2.1. Generic Instrument Interfaces 

One of the most important initial steps in a software develop- 
ment project is to define the structure of packages and their 
interfaces. In a telescope control system there is an additional 
need for interfaces to all the hardware devices that are being 
used for the observations. We therefore began to collect in- 
formation about typical setups at other radio observatories to 
eventually define a set of common instrument properties and 
methods (Mud erseTal. 2002l lMuders 2006). 

The important design decision was to require that instru- 
ments of the same kind (e.g. heterodyne receivers, spectral 
backends, etc.) must all use the same high-level interface. This 
simplifies the setup for the high-level observing software enor- 
mously because one merely adds a new instrument name with- 
out having to worry about adding new features at that level. 

The implementation of these generic interfaces using the 
CORBA middleware requires generic, though quite complex 
C++ code. We use a modified version of a code generator orig- 
inally developed at the U Bochum (R. Lemke priv. comm.) to 
automatically create these program files. 

The hardware side of these instrument interfaces is often 
served by very simple computers such as micro-controllers 
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Fig. 1. This diagram illustrates the APECS observing pipeline structure. The astronomer submits a request for a scan - encoded 
as a so-called Scan Object - to the Observing Engine which then coordinates all hardware and software tasks to perform the 
observation. It sets up the instruments, moves the telescope to the desired position and starts the data recording. The Raw Data 
Writer collects the data streams and creates an MBFITS file. After each subscan the Calibrator provides calibrated data and shows 
results on the online display for user feedback. 



which are not capable of running the quite large middleware 
code directly. Instead, we employ a simple text protocol fol- 
lowing the SCPI 3 standard (Hafo k, Muders & Olb erg 2006 1. 

2.2. MBFITS Raw Data Format 

In addition to the hardware interfaces, one also needs to 
determine the data product interfaces early on. There was 
a lack of modern single dish raw data data format de- 
scriptions when the APECS developments began. We there- 
fore defined a new data format called Multi-Beam FITS 
(MBFITS, |Muders, Polehampton & Hatchell 2005] > to store the 
raw APEX data. 

The MBFITS format was derived structurally from 
the ALMA Test Interferometer FITS (ALMA-TI FITS, 
|Lucas & Glendenn ing 2001 1 raw data format, although a num- 
ber of changes had to be made to accommodate the special 
needs of the APEX and also the IRAM 30m and Effelsberg 
100m telescopes where MBFITS is being used. 

The MBFITS format uses the FITS standard 
l |Wells, Greisen & Harten 1981) and the World Coordinate 
System JGreisen & Calabretta 2002> representation. MBFITS 
is based on the scan-subscan-integration scheme used by 
ALMA-TI fits and retains many of its keywords. However, due 
to the changes in structure and additional keywords needed to 
accommodate single-dish configurations, particularly multiple 
beam observing and multiple frontend/backend combina- 
tions, the MBFITS format can now be considered to be an 
independent format. 

For each level of time granularity (scan, subscan, backend 
integration) there are FITS binary tables to store the corre- 
sponding data. A special monitoring table allows to record im- 
portant instrument parameters in parallel to the backend data 
stream for later analysis. 



3 Standard Commands for Programmable Instrumentation, SCPI 
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2.3. Observer Interface 

The main observer interface is implemented as a command 
line interface (CLI) in a Python interpreter thus fulfilling the 
user requirement to have scripting with all options of a full 
programming language. The observing commands have been 
grouped according to functionality areas into catalog, target, in- 
strument, calibration, pattern and switch mode (e.g. wobbling 
or frequency switching) setups. We intentionally implemented 
first a CLI to facilitate user scripting. The future graphical user 
interface will use the existing commands. 

In general, the commands are designed to be similar to 
those found at other radio observatories. However, the typical 
setup of frontend-backend chains is simplified due to the use 
of Python's object-oriented features where we represent each 
instrument by an object whose methods are used for further 
setup. This is illustrated in the following example script to set 
up a 15 second on-off observation of the CO 7-6 line in Orion- 
KL with a sky reference 1,800" to the east using the FLASH 
810 GHz receiver ( |Heyminck et al. th is volu mejl connect ed to 
one of the FFTS spectrometers (Klei n et al. this volu me I in a 
configuration with 8192 spectral channels: 

source 'orion-kl' 
frontends 'flash810' 
flash810.1ine 'C0(7-6)' 
flash810.backends 'fftsl' 
fftsl numchan=8192 
reference 1800,0 
on 15 

2.4. Raw Data Writer 

The Raw Data Writer must collect the telescope positions, the 
backend data and the instrument configuration and write them 
to an MBFITS file. This is accomplished by a set of internal 
pipelines. Each backend that is selected for a scan is associ- 
ated with a Backend Pipeline that receives the backend data, 
processes it, and writes it to the corresponding MBFITS binary 
tables. 

The so-called Monitor Pipeline receives telescope (and in 
the future wobbler) position data, passes the data to the back- 
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end pipelines for interpolation, and also writes it to the file. 
In addition, it collects and writes user-defined monitor points 
from different devices. 

2.5. Data Calibrator 

The Data Calibrator ( Polehampton 2005 1 provides calibration, 
initial reduction, and display of data for both heterodyne and 
bolometer receivers. This includes feedback to the observing 
system for the basic pointing and focus observing modes. The 
reduction proceeds on a subscan-by-subscan basis, retaining 
entities that are required for further processing (e.g. references, 
calibrations). 

Heterodyne calibration to the T^ temperature scale is 
carried out using an extended version of the standard ra- 
dio astronomy chopper wheel technique on sky, hot and 
cold loads. The atmospheric calibration is calculated with 
the ATM model ( P ardo, Cernicharo & Serabyn 200 1) using the 
full Planck equation. The final calibrated spectra are written to 
disk in the CLASS 4 format. Bolometer data reduction is car- 
ried out using libraries of The Bolometer Data Analysis Project 
(Bo A, Bertold Tetall . 

An offline command line interface based on the Python in- 
terpreter is also provided for heterodyne data reduction. It uses 
exactly the same methods as for the online system. 

3. Deployment 

The APECS software is deployed at three main locations: 
the telescope itself, the control room at 5107 m altitude 5 on 
Chajnantor and the control room in the APEX base camp in 
Sequitor near San Pedro de Atacama which is connected to the 
mountain via a 32 Mbps microwave link. 

Three main servers provide the APECS pipeline system in- 
cluding the distributed objects representing the hardware, the 
Observing Engine, the Raw Data Writer and the Calibrator. A 
number of client stations are used for local or remote obser- 
vations from the high site or the base. Remote observing from 
the partner institutes in Europe is possible and has already been 
used. 

One important aspect of the APECS software is the deploy- 
ment in simulation mode on a single computer without the need 
for any real instrument hardware. This allows to test new devel- 
opments in an end-to-end fashion exactly as if performed at the 
telescope. 

4. Conclusion 

APECS is a modern, object-oriented telescope control sys- 
tem based on the ALMA software framework using CORBA 
as the middleware. Its generic interface approach greatly sim- 
plifies adding new instruments. The automatic monitoring of 
instrument properties facilitates debugging hardware prob- 
lems. The user-friendly, Python-based scripting language that 

4 The Gildas software. http://www.iram.fr/IRAMFR/GILDAS 

5 Operating hard disks at such a high altitude is technologically 
challenging due to the low air pressure that can lead to head crashes. 
APECS uses specially selected SCSI disks. 



is employed for observations and data calibration allows using 
many existing software libraries, thus saving much develop- 
ment time. New observing modes can be easily added at the 
scripting level. The new MBFITS raw data format provides 
a self-descriptive, self-contained way of storing all data that 
are necessary for further processing. The online data process- 
ing pipeline provides calibrated spectra and feedback for typ- 
ical calibration scans. Overall, APECS is now a mature tele- 
scope control system that can handle existing and planned in- 
struments and their data rates and has the potential for future 
extensions. 

Acknowledgements. We would like to thank the ALMA software de- 
velopers who helped us a lot to understand their software so that we 
could begin our own developments within that framework. 

References 

Bertoldi et al. BoA: The Bolometer Data Analysis Project, 
http://www.openboa.de 

Glendenning, B., Brooks, M., Chiozzi, G., Harris, G., Heald, R., 
Pisano, J,, Pokorny, M. & Staufter, F., 2001, Test Interferometer 
Control Software Design Concept, ALMA Report 

Greisen, E.W. & Calabretta, M.R., 2002 Representations of world co- 
ordinates in FITS, A&A, 395, 1061-1075 

Giisten, R., Nyman, L.A., Schilke, P., Menten, K., Cesarsky, C. & 
Booth, R., The Atacama Pathfinder Experiment (APEX), 2006, 
this volume 

Hafok, H., Muders, D. & Olberg, M., 2006, APEX SCPI Socket 

Command Syntax and Backend Data Stream Format, APEX 

Report APEX-MPI-IFD-0005, Rev. 1.0 
Heyminck, S., Kasemann, C, Giisten, R., de Lange, G. & Graf, U.U., 

2006, this volume 
Klein, B., Philipp, S.D., Kramer, I., Kasemann, C, Giisten, R. 

& Menten, K.M., The APEX Digital Fast Fourier Transform 

Spectrometer 2006, this volume 
Lucas, R. and Glendenning, B., 2001, 'ALMA Test Interferometer 

Raw Data Format', ALMA Report ALMA-SW-0015. 
Muders, D., 2005, APECS Observing & Operating Manual, APEX 

Report APEX-MPI-MAN-0011 
Muders, D., 2006, APEX Instruments Generic CORBA IDL 

Interfaces, APEX Report APEX-MPI-IFD-0004, Rev. 1.5 
Muders, D., Hatchell, I., Lemke, R., Olberg, M. & Hafok, H, 2002, 

Software Interfaces for Submillimeter Telescope Instrumentation, 

APEX Report APEX-IFD-MPI-0001 
Muders, D., Polehampton, E. & Hatchell, I., 2005, Multi-beam FITS 

Raw Data Format, APEX Report APEX-MPI-IFD-0002, Rev. 

1.57 

The Common Object Request Broker: 

Architecture and Specifications. Rev. 2.3, 
ftp://ftp.omg.org/pub/docs/formal/98- 12-01 .pdf Framingham, 
MA, USA 

Pardo, I. R., Cernicharo, I. & Serabyn, 2001, Atmospheric 
Transmission at Microwaves (ATM): An Improved Model for 
Millimeter/Submillimeter Applications, IEEE Trans, on Antennas 
and Propagation, 49, 1683 

Polehampton, E., 2005, APEX Calibrator Manual, APEX Report 
APEX-MPI-MAN-0012 

Raffi, G, Chiozzi, G. & Glendenning, B., 2001, The ALMA Common 
Software (ACS) as a basis for a distributed software development, 
ADASS XI 



D. Muders et al.: APECS - The Atacama Pathfinder Experiment Control System 



5 



Rossum, G. v., Drake Jr., F.L., 2001, Python Reference Manual, 

Release 2.2, http://www.python.org 
Wells, D. C, Greisen, E. W. & Harten, R. H„ 1981, FITS - a Flexible 

Image Transport System, A&AS, 44, 363-+ 



